Skip to content

feat: Add external plugins support - DO NOT MERGE #183

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mayabar
Copy link
Contributor

@mayabar mayabar commented Jun 15, 2025

Add initial version of server side support for external HTTP plugins.
Add sample filter plugin implemented in python

Fixes: #163
Fixes: #164
Fixes: #184

@mayabar mayabar requested review from shmuelk and kfirtoledo June 15, 2025 12:45
Copy link
Collaborator

@elevran elevran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not review beyond the first or second file.
IMO, this PR might be too big to review in one go and could benefit from breaking up (e.g.,):

  • design doc/proposal (which should be approved separately)
  • API definitions (e.g., JSON between client and server)
  • sample server (e.g., python) and client, for a fixed function.
  • improved client (e.g., configuration of http.Client for timeout handling, etc.)

There is no need to support all plugin types at once. Furthermore, since configuration via file is forthcoming, I would delay writing configuration code until it is merged. Otherwise it's throwaway code.

@@ -14,6 +14,7 @@ require (
github.com/prometheus/client_golang v1.22.0
github.com/redis/go-redis/v9 v9.7.3
github.com/stretchr/testify v1.10.0
github.com/valyala/fasthttp v1.62.0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

q: what's the benefit of using a non standard HTTP implementation? If performance, then we should first prove that HTTP handling is a bottleneck.

@@ -52,15 +54,49 @@ const (

prefixScorerBlockSizeEnvKey = "PREFIX_SCORER_BLOCK_SIZE"
prefixScorerBlockSizeDefault = 256

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point the external process plugin is for demo only, so I would refrain from introducing and using all these environment variables (which would be eliminated by the config changes anyway).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a demo, you can just enable (or not) a fixed type plugins (e.g., filter or scorer) at a well known address (e.g., localhost:8000/8088 and run their container(s) in the same Pod)

@@ -22,6 +22,7 @@ import (
logutil "sigs.k8s.io/gateway-api-inference-extension/pkg/epp/util/logging"

"github.com/llm-d/llm-d-inference-scheduler/pkg/config"
externalhttp "github.com/llm-d/llm-d-inference-scheduler/pkg/scheduling/plugins/external/http"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

import order seems wrong

@mayabar mayabar changed the title feat: Add external plugins support feat: Add external plugins support DON'T MERGE Jun 17, 2025
@mayabar mayabar changed the title feat: Add external plugins support DON'T MERGE feat: Add external plugins support - DO NOT MERGE Jun 17, 2025
@elevran elevran added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 17, 2025
@nirrozenbaum
Copy link
Collaborator

@elevran what’s the intention about this PR?
is it planned to be completed?
This PR seems to be open almost 2 months

@elevran
Copy link
Collaborator

elevran commented Aug 11, 2025

It is not intended to be merged at this time and was created to share ideas with community and to solicit feedback (the concept of out of process plugins was presented at a community meeting and had corresponding code for those interested).
Having an open PR is probably not the best way for this discussion, but we may want to have something tangible (not necessarily this PR) for people to experiment with.
Open to suggestions.

@nirrozenbaum
Copy link
Collaborator

one option would be to create a branch called experimental-out-of-process-plugins (or something alone these lines) and keep this code there.
it allows experimenting with it, and also to create a PR to main at any given point if we think it becomes relevant.
not sure that holding an open PR for this purpose is the right approach.

@elevran
Copy link
Collaborator

elevran commented Aug 12, 2025

Agree.
Let's clean it up as you suggested to a branch at earliest convenience (pre/post release - I don't think there's urgency)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create sample external plugin in python Server side of external plugins extension External plugins initialization
3 participants